The downside is, of course, that you can only access fields in your current "nesting level".

there's no need for child-validators to achieve that. to access the whole context it requires the possibility to use methods as callables.
that would imply that the default rule for callables should be named default_handler (similar to rename_handler) or alike to discriminate string values from methods.

i will probably do a code review this evening in europe.

here are my thoughts:

test_depending_... and test_default_callable_with_multiple_dependencies would be better readable if the keys in the schema were sorted alphabetically .

can circular dependencies be detected while schema validation? if yes, that would be preferable since it's easier to deal with errors prior to validation in client code and the document processing itself would be more lightweight.

I love this. Detecting circular dependencies during schema validation would be great.

test_depending_... and test_default_callable_with_multiple_dependencies would be better readable if the keys in the schema were sorted alphabetically .

You're right, I'm going to change this. The initial thought was to enforce a situation where _normalize_default has to delay the processing of at least one callable. But as the order of dict keys isn't predictable it does not make much sense to write it that way.

there's no need for child-validators to achieve that. to access the whole context it requires the possibility to use methods as callables.
that would imply that the default rule for callables should be named default_handler (similar to rename_handler) or alike to discriminate string values from methods.

Thanks for pointing to the rename_handler. I will delve deeper into the codebase over the weekend and try to make more sense of your comment after that ;).

Checking for circular dependencies during schema validation sounds good, but I'm afraid that will cover only "simple" cases (but those are probably the most common ones). I'd leave the error handling in _normalize_default, too. Otherwise we could end up in an infinite loop for more complex callables, e.g. callables that behave differently based on other document fields.

another thought:

why check for circular references at all? if such occurs, it's completely the developer's responsibility, right? i'm very much for anticipating user's mistakes, but i think developers can be left with their own fate when it becomes too complex to protect them from themselves. and there are certainly more potential mistakes a developer could make than circular references. so, essentially: every developer should test her/his code well.

Awesome. Thank you.

You're fast - this wasn't meant to be merged right away :). This is what the (wip) = (work in progress) should indicate. Sorry for the confusion!

I'd like to remove the commented out test at least and maybe add some comments for clarification, shall I open another Pull Request?

ah sorry about that. yup open another pr.